Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

app/views/settings/providers/_status_pill.html.erb (1)

2-8: ⚡ Quick win

Case statement computing CSS classes belongs in a helper or ViewComponent, not the template.

Per guidelines: "Keep domain logic out of views: compute values like button classes, conditional logic, and data transformations in the component file, not the template file." This partial is also reused across multiple views and has variants by status—criteria that specifically recommend a ViewComponent.

♻️ Suggested refactor — extract to a helper

# app/helpers/settings_helper.rb (or providers_helper.rb)
def status_pill_classes(status)
  case status.to_sym
  when :ok   then { dot: "bg-success",     pill: "bg-success/10 text-success" }
  when :warn then { dot: "bg-warning",     pill: "bg-warning/10 text-warning" }
  when :err  then { dot: "bg-destructive", pill: "bg-destructive/10 text-destructive" }
  else            { dot: "bg-gray-400",    pill: "bg-gray-100 text-secondary" }
  end
end

 <%# locals: (status:) %>
-<%
-  dot_class, pill_class = case status.to_sym
-  when :ok   then [ "bg-success",     "bg-success/10 text-success" ]
-  when :warn then [ "bg-warning",     "bg-warning/10 text-warning" ]
-  when :err  then [ "bg-destructive", "bg-destructive/10 text-destructive" ]
-  else            [ "bg-gray-400",    "bg-gray-100 text-secondary" ]
-  end
-%>
+<% classes = status_pill_classes(status) %>
+<% dot_class, pill_class = classes[:dot], classes[:pill] %>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_status_pill.html.erb` around lines 2 - 8, The
template currently contains presentation logic (the case statement building CSS
classes) which should be moved to a helper or ViewComponent; extract that logic
into a new helper method (e.g., status_pill_classes(status)) or a
StatusPillComponent that returns the dot and pill class values (as keys like
:dot and :pill), then update the partial to call status_pill_classes(status) and
use the returned classes instead of the inline case; ensure the helper/component
handles symbolizing the status and preserves the same mappings for :ok, :warn,
:err and the default case.

app/jobs/sync_all_providers_job.rb (1)

6-6: ⚡ Quick win

Use find_by with a nil guard to avoid unrecoverable job failures when a family is deleted mid-queue.

Family.find raises ActiveRecord::RecordNotFound if the record is gone by the time the job runs. With Sidekiq's default retry behavior this leads to repeated failures until retries are exhausted.

♻️ Proposed fix

-    family = Family.find(family_id)
-    family.sync_later
+    family = Family.find_by(id: family_id)
+    family&.sync_later

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/jobs/sync_all_providers_job.rb` at line 6, Replace the unsafe Family.find
lookup with a nil-safe lookup and early return: change the
Family.find(family_id) call to Family.find_by(id: family_id) and add a guard
like return unless family (or log and return) in the job's perform method (the
place where family = Family.find(...) is used) so the job exits gracefully if
the family was deleted instead of raising ActiveRecord::RecordNotFound and
retrying.

app/views/settings/_section.html.erb (1)

19-27: ⚡ Quick win

Generic section partial couples to a provider-specific partial.

_section.html.erb is a shared layout component, but line 24 hard-codes a dependency on "settings/providers/status_pill". If any other settings section ever needs a status: value (e.g., a future "Accounts" health section), it would either not render correctly or render an unrelated provider pill. The actions local already demonstrates the right pattern — pass pre-rendered content in from the caller.

♻️ Suggested approach

Pass the rendered pill from the call site (e.g. settings_section(status: render("settings/providers/status_pill", status: ...))), and drop the inline render from the generic partial:

-          <%= render "settings/providers/status_pill", status: status %>
+          <%= status if status.present? %>

The caller can then pass status: capture { render "settings/providers/status_pill", status: :ok } or any other rendered content, keeping _section.html.erb subsystem-agnostic.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/_section.html.erb` around lines 19 - 27, The shared
partial _section.html.erb currently hard-codes render
"settings/providers/status_pill" for the status display, coupling this generic
layout to a provider-specific partial; change it to accept rendered status
content from the caller (like actions already does) by removing the inline
render and using the passed-in status local as-is, and update callers to pass
status: render("settings/providers/status_pill", status: ...) or status: capture
{ render "settings/providers/status_pill", status: :ok } so _section.html.erb
remains subsystem-agnostic and callers control the actual markup.

app/views/settings/providers/show.html.erb (1)

1-18: ⚡ Quick win

Move the new page title and intro copy into i18n.

"Bank Sync" and the lede are hard-coded English while the surrounding UI already uses translations. Please switch these to t(...) so this page stays consistent with the rest of settings copy.

As per coding guidelines, "Always use t() helper for user-facing strings. Update config/locales/en.yml for new strings."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/show.html.erb` around lines 1 - 18, Replace the
hard-coded page title and intro copy in the view: change content_for
:page_title, "Bank Sync" to use t("settings.providers.bank_sync.page_title") and
replace the paragraph text ("Connect external accounts so transactions, balances
and holdings flow into Sure automatically.") with
t("settings.providers.bank_sync.lede"); then add corresponding entries under
settings.providers.bank_sync in config/locales/en.yml (page_title and lede) with
the existing English strings as values so the view uses the t(...) helper and
stays consistent with other translations.

app/components/settings/provider_card.rb (1)

2-18: ⚡ Quick win

Localize the maturity badge labels instead of hard-coding English here.

These strings are rendered in the UI, so storing "Beta" / "Alpha" in the component bypasses locale switching. Keep translation keys (or symbols) in the constant and resolve them with t(...) at render time.

As per coding guidelines, "Always use t() helper for user-facing strings. Update config/locales/en.yml for new strings."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/components/settings/provider_card.rb` around lines 2 - 18, Replace
hard-coded English labels in MATURITY_LABELS with translation keys (e.g., :beta
and :alpha or symbol strings) and resolve them via the Rails i18n helper in the
maturity_label method; specifically, keep MATURITY_LABELS as a mapping of
maturity symbols to translation keys, then update the maturity_label method to
call t(...) on the mapped key (using the t helper), and add the corresponding
entries under config/locales/en.yml so the UI strings are localized.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

test/system/settings/providers_test.rb (1)

25-27: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Scope the connect assertion to the SimpleFIN card.

This currently proves that the grid contains SimpleFIN somewhere and that some card has a Connect link. The test still passes if the SimpleFIN card loses its affordance and another provider supplies the link.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/system/settings/providers_test.rb` around lines 25 - 27, The test
currently checks the grid and the presence of a Connect link separately;
instead, scope the connect assertion to the SimpleFIN card by locating the
provider card element that contains the text "SimpleFIN" (e.g. find or within on
the element returned by available_provider_cards_container that has text
"SimpleFIN") and then assert that within that card there is an
"a[data-turbo-frame='drawer']" link with text "Connect"; update the assertions
around available_provider_cards_container and the SimpleFIN text to perform the
connect link check inside that card element rather than globally.

test/system/settings/providers_test.rb (1)

39-45: ⚡ Quick win

Prefer DOM-order assertions over native.location.y.

These checks depend on rendered pixel coordinates, which makes them much more brittle across driver and viewport changes than necessary. Asserting relative DOM order would cover the same behavior with a lot less flake risk.

Also applies to: 72-81, 137-140

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/system/settings/providers_test.rb` around lines 39 - 45, The test
currently compares pixel positions via connections_heading.native.location.y,
available_heading.native.location.y and page.find("details", text:
"SimpleFIN").native.location.y which is brittle; instead assert DOM order—locate
the same elements (connections_heading, available_heading, and the details
element matching "SimpleFIN") and assert their relative order using a DOM-based
approach (e.g. use Capybara XPath following/preceding relationships or compare
indices from page.all to ensure the details element appears after
connections_heading and before available_heading). Replace the three
native.location.y comparisons with these DOM-order assertions in the same
examples (also apply the same change to the other occurrences mentioned).

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/views/settings/providers/_coinstats_panel.html.erb (1)

4-6: ⚡ Quick win

Remove redundant .html_safe calls.

Rails I18n automatically marks translation keys ending in _html as HTML-safe. The explicit .html_safe calls on lines 4 and 6 are redundant and can be removed.

♻️ Proposed refactor

  <%= render "settings/providers/setup_steps",
             steps: [
-              t("coinstats_items.new.step1_html").html_safe,
+              t("coinstats_items.new.step1_html"),
               t("coinstats_items.new.step2"),
-              t("coinstats_items.new.step3_html", accounts_url: accounts_path).html_safe
+              t("coinstats_items.new.step3_html", accounts_url: accounts_path)
             ] %>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_coinstats_panel.html.erb` around lines 4 - 6,
Remove the redundant .html_safe calls on the translation helpers: replace
occurrences of t("coinstats_items.new.step1_html").html_safe and
t("coinstats_items.new.step3_html", accounts_url: accounts_path).html_safe with
plain t("coinstats_items.new.step1_html") and
t("coinstats_items.new.step3_html", accounts_url: accounts_path) respectively,
since Rails marks `_html` I18n keys as HTML-safe automatically.

app/views/settings/providers/_sophtron_panel.html.erb (1)

43-44: ⚡ Quick win

Consider extracting button styling to a reusable component.

The submit button uses a verbose inline class string with 13 utility classes. While the color tokens (text-inverse, bg-inverse, bg-inverse-hover, focus:ring-primary) correctly use design-system tokens, extracting this pattern into a DS::Button component (if one exists) or helper would improve maintainability and ensure consistency across forms.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_sophtron_panel.html.erb` around lines 43 - 44,
The submit button in the form uses a long inline class string on the form.submit
call; extract that styling into a reusable design-system button component or
helper (e.g., DS::Button or a view helper like sophtron_button_class) and
replace the inline class usage in the form.submit invocation (the call that uses
is_new_record and t("sophtron_items.sophtron_panel.save"/"update")) so the
markup passes a single component/helper and the label (derived from
is_new_record and t(...)) while the component encapsulates the utility classes
(text-inverse, bg-inverse, bg-inverse-hover, focus:ring-primary, etc.) and
ensures consistent styling across forms.

app/views/settings/providers/_simplefin_panel.html.erb (2)

2-7: ⚡ Quick win

Use i18n keys instead of hardcoded English strings.

The setup steps contain hardcoded English text. Per coding guidelines, user-facing strings should use the t() helper with hierarchical i18n keys. The PR objectives note that i18n is a known backlog item for 8 locales, but new English strings should still be added to config/locales/views/settings/en.yml to facilitate future translation.

🌐 Refactor to use i18n keys

Add keys to config/locales/views/settings/en.yml:

settings:
  providers:
    simplefin_panel:
      step_1_html: "Go to %{link} for a one-time setup token."
      step_2: "Paste the token below and connect."
      step_3: "Then head to Accounts to link your synced accounts."
      bridge_link_text: "SimpleFIN Bridge"

Then update the template:

  <%= render "settings/providers/setup_steps",
             steps: [
-              ("Go to " + link_to("SimpleFIN Bridge", "https://beta-bridge.simplefin.org", target: "_blank", rel: "noopener noreferrer", class: "text-primary font-medium underline") + " for a one-time setup token.").html_safe,
-              "Paste the token below and connect.",
-              "Then head to Accounts to link your synced accounts."
+              t("settings.providers.simplefin_panel.step_1_html", link: link_to(t("settings.providers.simplefin_panel.bridge_link_text"), "https://beta-bridge.simplefin.org", target: "_blank", rel: "noopener noreferrer", class: "text-primary font-medium underline")).html_safe,
+              t("settings.providers.simplefin_panel.step_2"),
+              t("settings.providers.simplefin_panel.step_3")
             ] %>

As per coding guidelines: "Always use t() helper for user-facing strings. Organize i18n keys hierarchically by feature."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_simplefin_panel.html.erb` around lines 2 - 7,
The template renders setup steps with hardcoded English strings; replace those
literals with i18n lookups using the t() helper and hierarchical keys (e.g.,
settings.providers.simplefin_panel.step_1_html, step_2, step_3 and
bridge_link_text) and update the call to render "settings/providers/setup_steps"
to pass the translated strings (step_1_html should use t(..., link:
link_to(...)) to keep the HTML link), and add the corresponding keys and English
values to config/locales/views/settings/en.yml so translations are available.

---

26-26: ⚡ Quick win

Replace raw Tailwind focus ring colors with design-system tokens.

The focus ring uses focus:ring-gray-900 and theme-dark:focus:ring-white, which are raw Tailwind color utilities. Per coding guidelines, use functional design-system tokens instead (e.g., focus:ring-primary or a focus token defined in sure-design-system.css).

♻️ Replace with design-system tokens

-                      class: "inline-flex items-center justify-center rounded-lg px-4 py-2 text-sm font-medium text-inverse button-bg-primary hover:button-bg-primary-hover focus:outline-none focus:ring-2 focus:ring-gray-900 theme-dark:focus:ring-white focus:ring-offset-2 transition-colors" %>
+                      class: "inline-flex items-center justify-center rounded-lg px-4 py-2 text-sm font-medium text-inverse button-bg-primary hover:button-bg-primary-hover focus:outline-none focus:ring-2 focus:ring-primary focus:ring-offset-2 transition-colors" %>

As per coding guidelines: "Always use functional tokens defined in design system such as text-primary instead of text-white, bg-container instead of bg-white, border border-primary instead of border border-gray-200."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_simplefin_panel.html.erb` at line 26, The focus
ring classes in the button class string on the SimpleFin panel (the long class
attribute in _simplefin_panel.html.erb) use raw Tailwind colors
`focus:ring-gray-900` and `theme-dark:focus:ring-white`; replace those with the
design-system focus tokens (for example `focus:ring-primary` or the appropriate
focus token from sure-design-system.css) so the class string uses functional
tokens instead of raw colors; update the class attribute where that button's
classes are defined to remove `focus:ring-gray-900` and
`theme-dark:focus:ring-white` and add the corresponding design-system token(s)
for both light and dark theme focus states.

app/views/settings/providers/_coinbase_panel.html.erb (2)

21-22: ⚡ Quick win

Replace raw Tailwind color utilities with design-system tokens.

Per the PR comments from jjmata and coding guidelines, avoid raw Tailwind utilities:

• Line 21: bg-[#0052FF] is a hardcoded hex color (Coinbase brand blue)
• Line 22: text-white should use a functional design-system token

If #0052FF is an intentional brand color, consider adding it to the design-system palette. Otherwise, use an existing surface token. For the icon text, use text-inverse or another appropriate functional token so it responds to themes.

♻️ Replace with design-system tokens

-            <div class="w-10 h-10 rounded-full bg-[`#0052FF`] flex items-center justify-center">
-              <%= icon "bitcoin", size: "md", class: "text-white" %>
+            <div class="w-10 h-10 rounded-full bg-brand-coinbase flex items-center justify-center">
+              <%= icon "bitcoin", size: "md", class: "text-inverse" %>
             </div>

Note: If bg-brand-coinbase doesn't exist in sure-design-system.css, add it or use an existing token like bg-accent.

As per coding guidelines: "Use Tailwind CSS design tokens (e.g., text-primary, bg-container) instead of raw Tailwind classes" and "Always use functional tokens defined in design system such as text-primary instead of text-white."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_coinbase_panel.html.erb` around lines 21 - 22,
Replace the hardcoded Tailwind color utilities in the Coinbase icon wrapper:
change the div class that contains bg-[`#0052FF`] and the icon call that uses
text-white to use design-system tokens instead (e.g., replace bg-[`#0052FF`] with
a token like bg-brand-coinbase or an existing token such as
bg-accent/bg-container, and replace text-white with a functional token like
text-inverse or text-primary). If bg-brand-coinbase does not exist in the design
system, add it to sure-design-system.css first; update the div with the new bg
token and update the icon invocation (icon "bitcoin") to use the chosen text
token so the element responds to theming.

---

76-76: ⚡ Quick win

Replace raw Tailwind focus ring color with design-system token.

The focus ring uses focus:ring-gray-900, which is a raw Tailwind color utility. Use a functional design-system token instead (e.g., focus:ring-primary).

♻️ Replace with design-system token

-                        class: "inline-flex items-center justify-center rounded-lg px-4 py-2 text-sm font-medium text-inverse bg-inverse hover:bg-inverse-hover focus:outline-none focus:ring-2 focus:ring-gray-900 focus:ring-offset-2 transition-colors" %>
+                        class: "inline-flex items-center justify-center rounded-lg px-4 py-2 text-sm font-medium text-inverse bg-inverse hover:bg-inverse-hover focus:outline-none focus:ring-2 focus:ring-primary focus:ring-offset-2 transition-colors" %>

As per coding guidelines: "Always use functional tokens defined in design system such as text-primary instead of text-white, bg-container instead of bg-white, border border-primary instead of border border-gray-200."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_coinbase_panel.html.erb` at line 76, The focus
ring utility in the button class uses the raw Tailwind color token
`focus:ring-gray-900`; update that utility to the design-system functional token
(e.g., replace `focus:ring-gray-900` with `focus:ring-primary`) wherever the
class string containing `inline-flex items-center ... focus:ring-gray-900` is
defined (the class attribute on the Coinbase panel button) so the component uses
the design-system token instead of a raw color.

app/controllers/settings/providers_controller.rb (3)

108-131: 💤 Low value

Silent redirect on unknown provider_key.

If a request supplies a provider_key that's neither in FAMILY_PANELS nor in the configuration registry, connect_form redirects to settings_providers_path with no flash. This will look like a no-op to the user. Consider an alert: notice (with a generic "Provider not found" key) for clarity and easier debugging.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/controllers/settings/providers_controller.rb` around lines 108 - 131, The
connect_form action currently redirects to settings_providers_path silently when
provider_key is not found in FAMILY_PANELS or Provider::ConfigurationRegistry;
change the final redirect to include an alert (e.g., use redirect_to
settings_providers_path, alert: t("settings.providers.not_found")) so users see
a "Provider not found" message and it's easier to debug unknown provider_key
values referenced by connect_form, FAMILY_PANELS, and
Provider::ConfigurationRegistry.

---

286-313: 💤 Low value

Naming collision around "stale".

has_error flags syncs where s.stale? is true (a sync that has been running too long), and the returned :stale field flags last-completed older than 24h ("data freshness"). Two different concepts share the same word, which makes downstream consumers ambiguous. Consider renaming the second to :data_stale (or similar) so callers — and the status pill helper — don't conflate them.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/controllers/settings/providers_controller.rb` around lines 286 - 313, The
returned hash from sync_health_for conflates two different meanings of "stale":
the local variable has_error checks s.stale? (a running sync) while the returned
key stale represents data freshness; rename the returned key to data_stale (or
similar) and update all callers (e.g., compute_provider_sync_health consumers
and any status pill helper or view code that reads :stale) to use the new key so
the running-sync flag (has_error) and data-freshness flag are unambiguous;
ensure you update any tests and serialization that expect :stale to :data_stale
and keep the logic for computing stale (last_synced < 24.hours.ago) unchanged.

---

97-106: 💤 Low value

sync silently no-ops when there are no syncable items.

If items is empty (or all are already syncing), nothing is enqueued but the user still sees the "sync in progress" notice. Consider a distinct notice (or no flash) when nothing was scheduled, so users aren't misled.

Suggested change

   items = syncable_type.constantize.where(family: Current.family).syncable
-  items.each { |item| item.sync_later unless item.syncing? }
-
-  redirect_to settings_providers_path, notice: t("settings.providers.sync_provider_in_progress")
+  enqueued = 0
+  items.each do |item|
+    next if item.syncing?
+    item.sync_later
+    enqueued += 1
+  end
+
+  notice_key = enqueued.positive? ? "settings.providers.sync_provider_in_progress" : "settings.providers.sync_nothing_to_do"
+  redirect_to settings_providers_path, notice: t(notice_key)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/controllers/settings/providers_controller.rb` around lines 97 - 106, The
sync action currently always redirects with the "sync in progress" notice even
when no items are scheduled; update the sync method (in
providers_controller#sync) to collect items that will actually be enqueued
(e.g., scheduled = items.reject(&:syncing?).each { |item| item.sync_later }) or
use items.select { |i| !i.syncing? } then call sync_later, and set the flash
based on scheduled.any? — if scheduled.any? use
t("settings.providers.sync_provider_in_progress"), otherwise set a different
notice/alert (or no flash) indicating "no items to sync" so users aren't misled.

app/views/settings/providers/_provider_form.html.erb (1)

4-15: 💤 Low value

Both step_1_html translation keys exist, but verify if EU panel needs separate step 2 and 3 instructions.

The dynamic step_1_html key correctly resolves to settings.providers.plaid_eu_panel.step_1_html for the EU provider. However, plaid_eu_panel only defines step_1_html—it does not have step_2 or step_3 keys. The code hardcodes steps 2 and 3 to always use plaid_panel.*. If the EU setup process requires different instructions for steps 2 and 3, add the missing keys to plaid_eu_panel and update the code to use the dynamic provider key there as well.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_provider_form.html.erb` around lines 4 - 15,
The setup_steps_data block builds translation keys using provider_key and
correctly uses step_1_key for step_1_html, but steps 2 and 3 are hardcoded to
"settings.providers.plaid_panel.step_2" and
"settings.providers.plaid_panel.step_3", which will miss translations for the EU
provider; update the code that builds setup_steps_data (the provider_key,
step_1_key, and the array construction in setup_steps_data) to derive step_2 and
step_3 keys dynamically from provider_key (e.g.
"settings.providers.#{provider_key}_panel.step_2" and step_3) or add the missing
step_2/step_3 keys to the plaid_eu_panel translations so the t(...) lookups for
step_2 and step_3 succeed.

app/views/settings/providers/_search_filters.html.erb (1)

9-9: ⚡ Quick win

Replace raw focus ring color with a DS token class.

focus:ring-gray-500 bypasses the design-token layer; this should use a functional token ring class for theme consistency.

Proposed patch

-           class="block w-full border border-secondary rounded-md py-2.5 pl-10 pr-3 bg-container focus:ring-gray-500 sm:text-sm">
+           class="block w-full border border-secondary rounded-md py-2.5 pl-10 pr-3 bg-container focus:ring-alpha-black-100 sm:text-sm">

As per coding guidelines: “Use Tailwind CSS design tokens … instead of raw Tailwind classes” and “Always prefer using functional tokens defined in sure-design-system.css … rather than raw Tailwind utilities.”

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/views/settings/providers/_search_filters.html.erb` at line 9, The element
in _search_filters.html.erb uses the raw utility focus:ring-gray-500; replace
that raw Tailwind color with the project's design-system focus token class from
sure-design-system.css (e.g. swap focus:ring-gray-500 for the functional token
class used for focus rings such as focus:ring-ds-focus or the project's
equivalent token name) so the input uses the DS theme token instead of a
hardcoded color; update the class attribute on the same element that currently
contains focus:ring-gray-500.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes